View CORESDR-M_871869.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

coresdr v4.0 handbook
actel corporation, mountain view, ca 94043 ? 2007 actel corporation. all rights reserved. printed in the united states of america part number: 50200104-1 release: april 2009 no part of this document may be copied or reproduced in any form or by any means without prior written consent of actel. actel makes no warranties with respect to this do cumentation and disclaims any implied warranties of merchantability or fitness for a particular purpose. information in this document is subject to change without notice. actel assumes no responsibility for any errors that may appear in this document. this document contains confidential proprietary information that is not to be disclosed to any unauthorized person without prior written consent of actel corporation. trademarks actel and the actel logo are registered trademarks of actel corporation. adobe and acrobat reader are registered trademarks of adobe systems, inc. all other products or brand names mentioned are tradem arks or registered trademarks of their respective holders.
v2.1 3 table of contents introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 key features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 supported device families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 core versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 device utilization and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 functional block description . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 sdram overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 coresdr operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 tool flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 smartdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 coresdr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 controller configuration ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 core interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 local bus signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 sdr sdram interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5 timing diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 sdram writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 sdram reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 auto-precharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 testbench operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 testbench description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7 ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ordering codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 a product support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 customer service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 actel customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 actel technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 contacting the customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . 29 index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

v2.1 5 introduction general description coresdr provides a high-performance interface to sing le-data-rate (sdr) synchronous dynamic random access memory (sdram) devices. coresdr accepts read and write commands using the simple local bus interface and translates these requests to the command sequences re quired by sdram devices. coresdr also performs all initialization and refresh functions. coresdr uses bank management techniques to monitor the status of each sdram bank. banks are only opened or closed when necessary, minimizing access delays. up to four banks can be managed at one time. access cascading is also supported, allowing read or write requests to be chained toge ther. this results in no delay between requests, enabling up to 100% memory throughput for sequential accesses. coresdr is provided with configurable memory settings (row bits and column bits) and timing parameters (cas latency, t ras , t rc , t rfc ,t rcd , t rp , t mrd , t rrd , t refc , t wr ). the memory settings are configured through the smartdesign gui. the timing parameters are configured by setting the coresdr inputs. this ensures compatibility with virtually any sdram configuration. the top-level interface diagram is shown in figure 1 . figure 1 i/o signal diagram clk reset_n raddr[30:0] b_size[3:0] r_req w_req auto_pch rw_ack d_req sa[13:0] w_valid ba[1:0] r_valid cs_n[7:0] sd_init cke ras_n ras[3:0] cas_n rcd[2:0] we_n rrd[1:0] dqm rp[2:0] oe rc[3:0] rfc[3:0] mrd[2:0] cl[2:0] bl[1:0] wr[1:0] delay[15:0] ref[15:0] colbits[2:0] rowbits[1:0] regdimm local bus configuration inputs sdram interface
introduction coresdr v4.0 6v2.1 key features ? high performance, single data rate controller for standard sdram chips and dual in-line memory modules (dimms) ? synchronous interface, fully pipelined internal architecture ? supports up to 1,024 mb of memory ? bank management logic monitors status of up to 8 sdram banks supported device families ?proasic?3 ?proasic3e ?proasic3l ?fusion ?axcelerator? core versions this handbook applies to coresdr v4.0. the release notes prov ided with the core list known discrepancies between this handbook and the core release associated with the release notes. device utilization and performance coresdr has been implemented in several actel device families. a summary of the implementation data is listed in table 1 . table 1 coresdr device utilization and performance family cells or tiles utilization performance sequential combinatorial total device total proasic3 492 858 1,350 a3p250-2 11% 133 mhz proasic3e proasic3l fusion 492 858 1,350 afs250-2 11% 133 mhz axcelerator 505 642 1,147 ax125-2 57% 153 mhz note: all data was obtained using a default system configuration with the local bus tied to internal user logic and the controller configuration inputs hard-coded. coresdr requ ires 62 fpga i/o pins wh en interfaced to a 32-bit sdram memory. all performance data was obtained under commercial (com) conditions.
v2.1 7 1 functional block description coresdr consists of the following primary blocks, as shown in figure 1-1 : 1. control and timing block C main controller logic 2. initialization control C performs in itialization sequence after reset_n is deactivated or sd_init is pulsed. 3. address generation C puts out address, bank addr ess, and chip select signals on sdram interface. 4. bank management C keeps track of last opened row and bank to minimize command overhead. 5. refresh control C performs automatic refr esh commands to maintain data integrity. for coresdr, the datapath is external to the core. the tristate buffer shown in figure 1-1 resides in the i/o and its output enable is controlled by the core. figure 1-1 coresdr block diagram address mapping the mapping of the raddr bus at the local bus interface to the chip select, row, column, and bank addresses is shown in figure 1-2 on page 8 . the exact bit positions of the mapping will vary depending on the rowbits and colbits configuration port settings. the column bits, bank bits, row bits, and chip sele ct are mapped from the least significant bank management refresh control control and timing cke ras_n cas_n we_n initialization control address generation sa[13:0] ba[1:0] cs_n[7:0] reset_n configuration inputs raddr[30:0] b_size[3:0] r_req w_req rw_ack d_req r_valid d_valid coresdr clk clk datain dataout oe dqm dqm dq sdram devices local bus sdram interface sd_init
functional block description coresdr v4.0 8v2.1 bits of raddr. by mapping the bank bits from this location, long accesses to contiguous address space are more likely to take place without the need for a precharge. figure 1-2 mapping raddr sdram overview the synchronous interface and fully pipelined internal architecture of sdram allow extremely fast data rates if used efficiently. sdram is organized in banks of memory addr essed by row and column. the number of row and column address bits depends on the size and configuration of the memory. sdram is controlled by bus commands that are formed using combinations of the ras_n, cas_n, and we_n signals. for instance, on a clock cycle where all three signals are high, the associated command is a no operation (nop). a nop is also indicated when the chip select is not asserted. the standard sdram bus commands are shown in table 1-1 . sdram devices are typically divided into four banks. these banks must be opened before a range of addresses can be written to or read from. the row and bank to be opened are registered coincident with the active command. when a new row on a bank is accessed for a read or a write, it may be necessary to first close the bank and then reopen it to the new row. the precharge command closes a bank. opening and closing banks costs memory bandwidth, so coresdr has been designed to monitor and manage the status of the four banks simultaneously. this enables the controller to intelligently open and close banks only when necessary. when the read or write command is issued, the initial column address is presented to the sdram devices. in the case of sdr sdram, the initial data is presented concurrent with the write command. for the read command, the initial data appears on the data bus 1C4 clock cycles later. this is known as cas latency and is due to the time required to physically read the internal dram and register the data on the bus. the cas latency depends on the speed grade of the sdram and the frequency of the memory clock. in general, the faster the clock, the more cycles of cas latency raddr column[colbits?1:0] bank[1:0] row[rowbits?1:0] cs_n[7:0] msb lsb 3 rowbits colbits 2 table 1-1 sdram bus commands command ras_n cas_n we_n nop h h h active l h h read h l h write h l l burst terminate h h l precharge l h l auto-refresh l l h load mode register l l l
coresdr v4.0 sdram overview v2.1 9 required. after the initial read or write command, sequential reads and writes will continue until the burst length is reached or a burst terminate command is issued. sdram devices support a burst length of up to eight data cycles. coresdr is capable of cascading bursts to maximize sdram bandwidth. sdram devices require periodic refresh operations to maintain the integrity of the stored data. coresdr automatically issues the auto-refresh command periodically. no user intervention is required. the load mode register command is used to configure the sdram operation. this register stores the cas latency, burst length, burst type, and write burst mode. coresdr supports a sequential burst type and programmed-length write burst mode . the sdr controller only writes to the base mode register. consult the sdram device specification for additional details on these registers. in sdram, each bank is an organized block of rows and columns. a data width of 4, 8, or 16 is written to or read from the sdr sdram by providing the bank, row, and column addresses. to reduce pin count, sdram row and column addresses are multiplexed on the same pins. table 1-2 lists the number of rows, columns, banks, and chip selects required for various standard discrete sdr sdram devices. the x4, x8 , and x16 stand for data width. the user needs to check the sdram specification and set the row, column, and bank bits. coresdr will support any of these devices. sdram is typically available in dual in-line memory modules (dimms), small outline dimms (so-dimms), and discrete chips. the number of row and column bits for a dimm or so-dimm configuration can be found by determining the configuration of the disc rete chips used on the module. this in formation is available in the module datasheet. table 1-2 standard sdr sd ram device configurations chip size configuration rows columns banks 64 mb 16m4 12 10 4 64 mb 8m8 12 9 4 64 mb 4m16 12 8 4 64 mb 2m32 11 8 4 128 mb 32m4 12 11 4 128 mb 16m8 12 10 4 128 mb 8m16 12 9 4 128 mb 4m32 12 8 4 256 mb 64m4 13 11 4 256 mb 32m8 13 10 4 256 mb 16m16 13 9 4 512 mb 128m4 13 12 4 512 mb 64m8 13 11 4 512 mb 32m16 13 10 4 1,024 mb 256m4 14 12 4 1,024 mb 128m8 14 11 4 1,024 mb 64m16 14 10 4
functional block description coresdr v4.0 10 v2.1 coresdr operation initialization after reset_n is deasserted or sd_init is pu lsed, coresdr performs the following sequence: 1. nop command is issued for 200 s (period controlled by the delay port parameter). 2. precharge-all command 3. eight auto-refresh commands 4. load mode register command C this causes the sdram mode register to be loaded with the proper burst length (bl) and cas latency (cl) values. coresdr initialization timing is shown in figure 1-3 . figure 1-3 sdr in itialization sequence auto-refresh sdram devices require periodic auto-refresh commands to maintain data integrity. coresdr will automatically issue periodic auto-refresh commands to the sdram device(s) without user intervention. the refresh period configuration port (ref ) specifies the period between refreshes, in clock cycles. figure 1-4 shows an example of two refresh commands. the first refresh sequence occurs when one or more banks have been left open as a result of a read without precharge or write without precharge operation. all open banks are closed using the precharge-all command (ras_n, we_n asserted with sa[10] and sa[8]) prior to the refresh command. in figure 1-4 , a refresh occurs again after the refresh period has elapsed, as determined using the ref configuration port. the re fresh will never interrupt a read or write in the middle of a data burst. however, if the controller determines that the refresh period has elapsed at a point concurrent with or prior 200 s of nop clk reset_n cke sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n dqm 0500 mode 0 ff 00 00 00 00 8 auto-refresh commands initialization complete t rp t rfc
coresdr v4.0 coresdr operation v2.1 11 to a read or write request, the request may be held off (rw_ack will not get asserted) until after the refresh has been performed. figure 1-4 refresh timing bank management coresdr incorporates bank management techniques to minimize command overhead. for each bank, the controller records the last opened row and whether the bank has been closed or not. when a local bus interface read or write request occurs, coresdr checks to determine if the requested bank is already opened and whether the request is for the same row as the one the bank is already opened with. if the bank is already opened with the requested row, coresdr performs the function immediately. if the bank is opened to a different row, the controller closes the bank (using the precharge command) and reopens the bank (using the active command) to the requested row. if the bank is already closed, the controller opens the bank to the requested row (using the active command). requests to the controller can be issued as read with auto-precharge , write with auto-precharge , read without auto-precharge , and write without auto-precharge . commands are issued with auto-precharge if the auto_pch signal is set concurrent with the read request (r_req) or write request (w_req) signals. after a read with auto-precharge or write with auto- precharge, the accessed bank is automatically closed inte rnally by the sdram device(s). after a read without auto- precharge or write without auto-precharge, the accessed bank is left open until closing is required. closing will occur whenever a request is issued to a row different from the row a bank is already open to, or during the next refresh sequence. the refresh sequence will close all the banks (using the precharge-all command) if all banks are not already closed. the default configuration of the controller tracks the status of four banks at a time. this means that an access to row a on bank a on chip select a is treated differently from an access to row a on bank a on chip select b . therefore, a close and open sequence is performed when switching between these rows. t rp t refc clk sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n 0500 0 00 00 00

v2.1 13 2 tool flows licenses coresdr is licensed in two ways. depending on your license, tool flow functionality may be limited. obfuscated complete rtl code is provided for the core, enabling th e core to be instantiated with smartdesign. simulation, synthesis, and layout can be performed with actel libero id e. the rtl code for the core is obfuscated, and some of the testbench source files are not provided. they are pre-compiled into the compiled simulation library instead. rtl complete rtl source code is provided for the core and testbenches. smartdesign the core can be configured using the configur ation gui within smartdesign, as shown in figure 2-1 . figure 2-1 coresdr configu ration within smartdesign
tool flows coresdr v4.0 14 v2.1 importing into libero ide coresdr is available for download to the smartdesign ip catalog, via the libero ide web repository. for information on using smartdesign to instantiate, configure, connect, and generate cores, refer to the libero ide online help. simulation flows to run simulations, select the user testbench within the smartdesign coresdr configuration gui, right-click, and select generate design ( figure 2-1 on page 13 ). when smartdesign generates the design files, it will install the appropriate testbench files. to run the simulation, set the design root to the coresdr instantiation in the libero ide design hierarchy pane, and click the simulation icon in the libero ide design flow window. this will invoke model sim? and automatically run the simulation. synthesis in libero ide set the design root appropriately and click the synthesis icon in the libero ide. the synthesis window appears, displaying the synplicity? project. set synplicity to use the verilog 2001 standard if verilog is being used. to perform synthesis, click the run icon. place-and-route in libero ide having set the design route appropr iately and run synthesis, click the layout icon in libero ide to invoke designer. coresdr requires no special place-and-route settings.
v2.1 15 3 coresdr generics customers can define the generics listed in table 3-1 as required in the source code. controller configuration ports coresdr is configured using runtime-programmable configuration ports. these ports can be tied off by the user to fixed values or programmed at runtime. these values should not change after reset_n is deasserted. table 3-2 lists the configuration ports. table 3-1 coresdr generics generic default setting valid values description sdram_chips 8 1 to 8 number of chip selects sdram_colbits 12 8 to 12 maximum number of sdram column bits sdram_rowbits 14 11 to 14 maximum number of sdram row bits sdram_chipbits 3 1 to 3 number of encoded chip select bits sdram_bankstat modules 44 and 8 number of bank status modules used (refer to bank management on page 11 for additional information) family 16 11 15 16 17 22 must be set to match the supported fpga family. 11 C axcelerator 15 C proasic3 16 C proasic3e 17 C fusion 22 C proasic3l table 3-2 sdram co ntroller parameters parameter port bits valid values description ras 4 1C10 sdram active to precharge (t ras ), specified in clock cycles rcd 3 2C5 sdram active to read or write delay (t rcd ), specified in clock cycles rrd 2 2C3 sdram active bank a to active bank b (t rrd ), specified in clock cycles rp 3 1C4 sdram precharge command period (t rp ), specified in clock cycles rc 4 3C12 sdram active to active / auto-refresh command period (t rc ), specified in clock cycles rfc 4 2C14 auto-refresh to active / auto-refresh command period (t rfc ), specified in clock cycles mrd 3 1C7 sdram load mode register command to active or refresh command (t mrd ), specified in clock cycles cl 3 1C4 sdram cas latency, specified in clock cycles
coresdr coresdr v4.0 16 v2.1 bl 2 0C3 sdram maximum burst length (encoded). values are decoded as follows: 0: 1 transfer/burst 1: 2 transfers/burst 2: 4 transfers/burst 3: 8 transfers/burst (valid for sdr only) wr 2 1C3 sdram write recovery time (t wr ) delay 16 10C65,535 ns delay after a reset event that the controller wait s before initializing the sdram, specified in clock cycles. per jedec standards, sdr devices require this delay to be a minimum of 200 s. ref 16 10C65,535 ns period between auto-refresh commands issued by the controller, specified in clock cycles. ref = auto refresh interval / t ck , where t ck is the clock cycle in ns. colbits 3 3C7 number of bits in the column address (e ncoded). values are decoded as follows: 3: 8 column bits 4: 9 column bits 5: 10 column bits 6: 11 column bits 7: 12 column bits rowbits 2 0C3 number of bits in the row address (encoded). values are decoded as follows: 0: 11 row bits 1: 12 row bits 2: 13 row bits 3: 14 row bits regdimm 1 0C1 set when using registered/buffered dimms. causes adjustment in local bus interface timing to synchronize with sdram command timing delayed by register/buffer on dimm. table 3-2 sdram controller parameters (continued) parameter port bits valid values description
coresdr v4.0 controller configuration ports v2.1 17 for example: if rcd is 20 ns in the specification and the clock is 133 mh z, then the number of clocks equals to 20/7.5=3. the user needs to hardcode the rcd ports to the binary value "011" in the top level since the value is "3". if rcd is 20 ns in the specification and the clock is 100m hz, then the number of clocks equals to 20/10=2. if it's divisible without a remainder, then set it to the next integer, wh ich is 3 in the above example, so that there will be little margin. the user needs to hardcode the rcd ports to the binary value "011" in the top level since the value is "3". example settings for the timing-related parameters are shown in table 3-3 . these settings are based on the speed grade of the sdram devices and the desired operating frequency. consult the datasheet for the sdram device you are using for the specific timing values of that device. table 3-3 example controller parameter values for coresdr parameter 100 mhz (10 ns period) 1 133 mhz (7.5 ns period) 2 specification value specification value ras 44.0 ns 5 37.0 ns 6 rcd 20.0 ns 3 15.0 ns 3 rrd 15.0 ns 2 14.0 ns 2 rp 20.0 ns 3 15.0 ns 3 rc 66.0 ns 7 60.0 ns 8 rfc 66.0 ns 7 66.0 ns 9 mrd 2 clks 2 2 clks 2 cl C 2 C 2 wr 15.0 ns 2 14.0 ns 2 delay 200 s 20,000 200 s 26,667 ref 7.8125 s 781 7.8125 s 1,041 notes: 1. values based on micron mt48lc32m8a2-75 2. values based on micron mt48lc32m8a2-7e

v2.1 19 4 core interfaces the port signals for coresdr are defined in table 4-1 below, table 4-2 on page 20 , and table 1 on page 6 . the port signals are also illustrated in figure 1-1 on page 7 . all signals are designated either in put (input-only) or output (output- only). local bus signals the user interface to coresdr is referred to as the local bus interface. the local bus signals are shown in table 4-1 . table 4-1 local bus signals signal name i/o description clk clock input system clock. all local bus signals are synchronous to this clock. reset_n reset input system reset raddr[30:0] memory address input local bus address b_size[3:0] burst size input local bus burst length. valid values are 1 through bl, where bl is the programmed burst length. (refer to table 3-2 on page 15 for discussion of the bl parameter.) r_req read request input local bus read request w_req write request input local bus write request auto_pch auto-precharge request input when asserted in conjunction with r_req or w_req, causes command to be issued as read with auto-precharge or write with auto-precharge , respectively. rw_ack read/write acknowledge output acknowledgement of read or write request d_req data request output requests data on the local bus write data bus (datain) during a write transaction. asserts one clock cycle prior to when data is required. w_valid write data valid output frames the active data being written to sdram. mimics d_req, except that it is delayed by one clock cycle. this signal is typically not used and is retained for legacy compatibility. r_valid read data valid output indicates that the data on the local bus read data bus (dataout) is valid during a read cycle. sd_init initialization strobe input causes coresdr to reissue the initialization sequence to sdram devices. coresdr will always issue the initializ ation sequence (including the startup delay) after reset, regardless of the sd_init state. this signal can be tied low if runtime reinitialization is not required. notes: 1. all control signals are active high except reset_n. 2. all local bus signals are synchronous to clk.
core interfaces coresdr v4.0 20 v2.1 sdr sdram interface signals the external interface to sdram devices is referred to as the sdram interface. the sdram interface signals are shown in table 4-2 . table 4-2 sdr sdra m interface signals signal name i/o description sa[13:0] address bus output sampled during the active , precharge , read , and write commands. this bus also provides the mode register value during the load mode register command. ba[1:0] bank address output sampled during active , precharge , read , and write commands to determine which bank command is to be applied to. cs_n[7:0] chip selects output sdram chip selects cke clock enable output sdram clock enable. held low during reset to ensure sdram dq and dqs outputs are in the high-impedance state. ras_n row address strobe output sdram command input cas_n column address strobe output sdram command input we_n write enable output sdram command input dqm data mask output sdram data mask asserted by controller during sdram initialization and during burst terminate. user may sum with user data mask bits. oe output enable output tristate control for dq data
v2.1 21 5 timing diagrams sdram writes the user requests writes at the local bus interface by asse rting the w_req signal and driving the starting address and burst size on raddr and b_size, respectively. the auto_pch may also be asserted with w_req to cause the write to be issued as a write with auto-precharge . the rules for write requests at the local bus interface are as follows: 1. once w_req is asserted, it must remain asserted until rw_ack is asserted by coresdr. after rw_ack is asserted by coresdr, w_req may remain asserted to re quest a follow-on write transaction. the w_req signal may remain asserted over any number of rw_ack pulses to generate any number of cascaded write bursts. the only time w_req may be deasserted is during the clock cycle immediately following the rw_ack pulse from coresdr. 2. the signals raddr, b_size, and auto_pch must maintain static values from the point when w_req becomes asserted until coresdr asserts rw_ack. th e raddr, b_size, and auto_pch signals may only change values in the clock cycle immediately following the rw_ack pulse from coresdr or when w_req is deasserted. 3. the w_req signal may not be asserted while the read request signal (r_req) is asserted. 4. the data request signal (d_req) will assert one clock prio r to when the user must present data at the datain bus. 5. the timing relationship between an initial w_req as sertion and an rw_ack assertion, or between rw_ack pulses as a result of multiple cascaded writes, will vary depending on the status of the banks being accessed, configuration port settings, refresh status , and initialization status. the user logi c should not rely on any fixed timing relationship between w_req and rw_ack. example coresdr write sequence figure 5-1 on page 22 shows an example coresdr write sequence. in this sequence, two writes are requested, both to the same bank and row. the first write request is for a burst size of eight; the second is for a burst size of five. the write request signal (w_req) is first asserted with the starting address (raddr) and the burst size (b_size). as a result of this request, coresdr asserts the row address (sa) , bank address (ba), and chip select (cs_n) with the active command to open the bank to the requested row. next, coresd r requests data from the user at the local bus interface using the d_req signal and acknowledges the write request by asserting rw_ack. at the next clock, coresdr begins writing the data to the sdram devices. eight data cycles are transferred. the local bus interface write request (w _req) remains asserted after rw_ack is asserted by coresdr to request an additional write burst. after the rw_ack pulse, the local bus interface changes the address and changes the burst size to five. as soon as the eight write cycles from the previous request are processed, the next write command is issued by coresdr, and the five data cycles for the new burst begin. in the case of this example, the second write was to the same bank and row as the first write. if the second write had been to a different bank or row, coresdr would have issued precharge and/or activate commands prior to the write command. since the burst size (b_size) of the second write request is less than the programmed sdr sdram burst length, the burst must be terminated using the burst terminate command. coresdr does this automatically, asserting we_n five clock cycles after the write command was issued. the dqm signal is also asserted during the burst terminate command to comply with jedec specifications. as demonstrated in figure 5-1 on page 22 , the output enable signal (oe) goes active one clock cycle before the data is actually required at the dq outputs. this is to accommodate long clock to out delays th at may exist in pld or asic tristate drivers. the oe signal stays asserted until the last data element is written.
timing diagrams coresdr v4.0 22 v2.1 figure 5-1 coresdr burst write note: for the case shown, rcd = 3, bl = 2, and regdimm = 0. sdram reads the user requests reads at the local interface by asserting the r_req signal and driving the starting address and burst size on raddr and b_size, respectively. the auto_pch may also be asserted with r_req to cause the read to be issued as a read with auto-precharge . the rules for read requests at the local interface are as follows: 1. once r_req is asserted, it must remain asserted until rw_ack is asserted by coresdr. after rw_ack is asserted by coresdr, r_req may remain asserted to re quest a follow-on read transaction. r_req may remain asserted over any number of rw_ack pulses to genera te any number of cascaded read bursts. the only time r_req may be deasserted is during the clock cycle immediately following the rw_ack pulse from coresdr. 2. the signals raddr, b_size, and auto_pch must maint ain static values from the point when r_req is asserted until coresdr asserts rw_ack. raddr, b_siz e, and auto_pch may only change values in the clock cycle immediately following the rw_ack pulse from coresdr, or when r_req is deasserted. 3. the r_req signal may not be asserted while the write request signal (w_req) is asserted. 4. the read data valid signal (r_valid) will assert when valid data is available at the dataout bus. 5. the timing relationship between an initial r_req as sertion and an rw_ack asse rtion, or between rw_ack pulses as a result of multiple cascaded reads, will va ry depending on the status of the banks being accessed, configuration port settings, refresh status , and initialization status. the user logi c should not rely on any fixed timing relationship between r_req and rw_ack. w_req r_req auto_pch raddr[30:0] b_size[3:0] rw_ack d_req datain dataout sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n oe dq dqm address 1 address 2 85 01234567012345 row column 1 column 2 bank chip 012345670123 local interface sdram interface write request #1 write request #2 write burst #1 write burst #2 clk
coresdr v4.0 sdram reads v2.1 23 example coresdr read sequence figure 5-2 shows an example coresdr read sequence. in this sequence, two reads are requested, both to the same bank and row. the first read request is for a burst size of eight, the second is for a burst size of five. the read request signal (r_req) is first asserted with the starting address (raddr ) and the burst size (b_size). as a result of this first request, coresdr asserts the row address (sa), bank address (ba), and chip select (cs_n) with the active command to open the bank to the requested row. next, coresdr acknowledges the read request by asserting rw_ack. since the cas latency is set at two in this case, read data appear s at dataout two clock cycles after coresdr issues the read command. coresdr asserts the r_valid signal to indicate valid data at the dataout bus. eight data cycles are transferred. the local bus interface read request (r_req) remains asserted after rw_ack is asserted by coresdr to request an additional read burst. after the rw_ack pulse, the local bus interface changes the address and changes the burst size to five. coresdr issues the next read command to the sdram devices as soon as is possib le to avoid interruption in the data flow. in the case of this example, the second read was to the same bank and row as the first read. if the second read had been to a different bank or row, coresdr would have issued precharge and/or activate commands prior to the read command. since the burst size (b_size) of the second read request is less than the programmed sdr sdram burst length, the burst must be terminated using the burst terminate command. coresdr does this automatically, asserting we_n five clock cycles after the read command was issued. coresdr never asserts the dqm signal while read data is tr ansacting. user logic must never assert dqm while read data is transacting, as this will cause the sdram devices to drive high-impedance instead of valid data. figure 5-2 coresdr burst read note: for the case shown, bl = 3, rcd = 3,wr = 2, rp = 3, cl = 2, and regdimm = 0. clk r_req w_req auto_pch raddr[30:0] b_size[3:0] rw_ack r_valid datain dataout sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n oe dq dqm 85 0123456701234 row 0123456701234 local interface sdram interface read request #1 read request #2 read burst #1 read burst #2 column 2 column 1 bank address 2 address 1 chip
timing diagrams coresdr v4.0 24 v2.1 auto-precharge read commands can be issued to the sdram devices as read with auto-precharge or read without auto-precharge . likewise, write commands can be issued to the sdram devices as write with auto-precharge or write without auto- precharge . if the auto-precharge option is used, the sdram device will automatically close (precharge) banks being read from or written to at the end of the transaction. any subsequent reads or writes to these banks will not require an explicit precharge command from coresdr. the user selects whether read or write commands are issued with auto-precharge using the auto_pch signal. if auto_pch is asserted along with w_req or r_req, the command will be issued to the sdram with auto-precharge. the auto-precharge option is useful in situations where the requested read or write addresses tend to be random. with random address sequences, banks are seldom left open with the exact row required by a subsequent request. if the auto-precharge was not used for the previous access to a bank, subsequent transactions to that bank first require the bank to be closed (precharged), causing a delay in the transaction. if auto- precharge was used for the previous access, the bank is already closed and ready to be opened to the desired row. figure 5-3 shows example transactions using the auto-precharge feature for coresdr. in the example, two write requests are issued, the first using auto-precharge and the second not using auto-precharge. both requests are to the same bank, but may be to different rows. coresdr issues the first command as a write with auto-precharge by driving bit sa[10] high during the write command. coresdr issues the second command as a write without auto-precharge by driving bit sa[10] low during the write command. since the first and second requests are to the same bank, coresdr must wait before reopening the bank to meet the sdram t wr and t rp requirements. if the first and second requests were to different banks, the second request would follow the first request such that there would be no interruption in data flow. figure 5-3 coresdr burst writes with auto-precharge option note: for the case shown, bl = 3, rcd = 3, wr = 2, rp = 3, cl = 2, and regdimm = 0. clk w_req r_req auto_pch raddr[30:0] b_size[3:0] rw_ack d_req datain dataout sa[13:0] sa[10] ba[1:0] cs_n[7:0] ras_n cas_n we_n oe dq dqm 8 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 row column 2 01234567 8 9 10 11 12 13 14 15 local interface sdram interface t wr t rp write req w/ auto-precharge write req w/o auto-precharge column 2 row bank column 1 chip address 2 address 1
v2.1 25 6 testbench operation two testbenches are provided with coresdr: ?verilog testbench ?vhdl testbench testbench description included with the obfuscated and rtl releases of coresdr is a user testbench that gives an example of coresdr usage. a simplified block diagram of the testbench is shown in figure 6-1 . by default, the verilog version, tb_user.v , instantiates a micron 256 mbit sdram model ( mt48lc16m16a2.v , 4m16 4 banks). the vhdl version, tb_user.vhd, instantiates a micron 64 mbit sdram model ( mt48lc4m16a2.vhd , 1m16 4 banks). the testbench instantiates the dut (design under test), which is the core sdr macro, the sdram model, as well as the test vector modules that provide stimuli sources for the dut. a proc edural testbench controls each module and applies the sequential stimuli to the dut. figure 6-1 coresdr testbench verilog user testbench the verilog user testbench is provided as a reference and can be modified to suit your needs. the source code for the verilog user testbench is provided to ease the process of integrating the coresdr macro into your design and verifying its functionality. vhdl user testbench the vhdl user testbench is provided as a reference and can be modified to suit your needs. the source code for the vhdl testbench is provided to ease the process of integr ating the coresdr macro into your design and verifying its functionality. coresdr procedural testbench sdram model

v2.1 27 7 ordering information ordering codes coresdr can be ordered through your local actel sales representative. it should be ordered using the following number scheme: coresdr-xx, where xx is listed in table 7-1 . table 7-1 ordering codes xx description om rtl for obfuscated rtl C multiple-use license rm rtl for rtl source C multiple-use license note: coresdr-om is included free with a libero ide license

v2.1 29 a product support actel backs its products with various support services including customer service, a customer technical support center, a web site, an ftp site, electronic mail, and worldw ide sales offices. this append ix contains info rmation about contacting actel and usin g these support services. customer service contact customer service for non-technical product support , such as product pricing, product upgrades, update information, order status, and authorization. from northeast and north central u.s.a., call 650.318.4480 from southeast and southwest u.s.a., call 650. 318.4480 from south central u.s.a., call 650.318.4434 from northwest u.s.a., call 650.318.4434 from canada, call 650.318.4480 from europe, call 650.318.4252 or +44 (0) 1276 401 500 from japan, call 650.318.4743 from the rest of the world, call 650.318.4743 fax, from anywhere in the world 650.318.8044 actel customer technical support center actel staffs its customer technical support center with highly skilled engineers who can help answer your hardware, software, and design questions. the custo mer technical support center spends a gr eat deal of time creating application notes and answers to faqs. so, before you contact us, please visi t our online resources. it is very likely we have already answered your questions. actel technical support visit the actel customer support website ( www.actel.com/custsup/search.html ) for more information and support. many answers available on the searchable web resource includ e diagrams, illustrations, and links to other resources on the actel web site. website you can browse a variety of technical and non-technical information on actels home page , at www.actel.com . contacting the customer technical support center highly skilled engineers staff the technical support center from 7:00 a . m . to 6:00 p . m ., pacific time, monday through friday. several ways of co ntacting the center follow: email you can communicate your technical questions to our email address and receive answers back by email, fax, or phone. also, if you have design problems, you can email your design files to receive assistance. we constantly monitor the email account throughout the day. when sending your request to us, please be sure to include your full name, company name, and your contact information for effi cient processing of your request. the technical support email address is tech@actel.com .
product support coresdr v4.0 30 v2.1 phone our technical support center answers all calls. the center re trieves information, such as your name, company name, phone number and your question, and then issues a case number. the center then forwards the information to a queue where the first available application engineer receives the data and returns your call. the phone hours are from 7:00 a . m . to 6:00 p . m ., pacific time, monday through friday. the technical support numbers are: 650.318.4460 800.262.1060 customers needing assistance outside the us time zones can either contact technical support via email ( tech@actel.com ) or contact a local sales office. sales office listings can be found at www.actel.com/contact/offices/index.html .
v2.1 31 a actel electronic mail 29 telephone 30 web-based technical support 29 website 29 address mapping 7 auto-precharge 24 auto-refresh 10 b bank management 5 , 11 block diagram 7 bus commands 8 c configuration ports 15 contacting actel customer service 29 electronic mail 29 telephone 30 web-based technical support 29 core interfaces 19 customer service 29 d device utilization and performance 6 g general description 5 generics 15 i initialization 10 instruction timing 10 auto-refresh 10 bank management 11 initialization 10 l libero integrated design environment (ide) importing into 14 place-and-route 14 simulation 14 synthesis 14 licenses 13 local bus signals 19 o obfuscated license 13 operation 8 ordering code 27 p parameters 15 product support 29 ? 30 customer service 29 electronic mail 29 technical support 29 telephone 30 website 29 r rtl license 13 s sdram bus commands 8 commands 8 device configurations 9 interface signals 20 reads 22 writes 21 simulation flows 14 t technical support 29 testbenches description 25 operation 25 , 27 verilog 25 vhdl 25 timing auto-precharge 24 diagrams 21 sdram reads 22 sdram writes 21 tool flows 13 v versions 6 index
32 v2.1 index coresdr v4.0 w web-based technical support 29

actel corporation ? 2061 stierlin court ? mountain view, ca 94043 ? usa phone 650.318.4200 ? fax 650.318.4600 ? customer service: 6 50.318.1010 ? customer applications center: 800.262.1060 actel europe ltd . ? river court, meadows business park ? station approach, blackwater ? camb erley surrey gu17 9ab ? united kingdom phone +44 (0) 1276 609 300 ? fax +44 (0) 1276 607 540 actel japan ? exos ebisu building 4f ? 1-24-14 ebisu shibuya-ku ? tokyo 150 ? japan phone +81.03.3445.7671 ? fax +81.03.3445.7668 ? http://jp.actel.com actel hong kong ? room 2107, china resources building ? 26 harbour road ? wanchai ? hong kong phone +852 2185 6460 ? fax +852 2185 6488 ? www.actel.com.cn 50200104-1/4.09 actel is the leader in low-power and mixed-signal fpgas and offers the most comprehensive portfolio of system and power management solutions. power matters. learn more at www.actel.com.

▲Up To Search▲

Price & Availability of CORESDR-M

	To Download CORESDR-M Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .